InfoMagic Internet Tools 1995 April/Internet Tools.iso/security/firewall.Z/firewall

Text File | 1991-06-25 | 60.0 KB | 1,323 lines

------8<------8<------8<------8<------8<------8<------8<------8<------8<------

Message-Id: <[e-mail]>
From: [e-mail]
To: Keith McNeill <[e-mail]>
Cc: [e-mail], [e-mail]
Subject: Re: Need firewall telnet/ftp gateway
Date: Thu, 25 Apr 91 11:58:07 EDT
Sender: [e-mail]

Also see Bill Cheswick's paper in the Summer '90 (Anaheim) Usenix
proceedings, on the application-level gateway we use.  Among other
things, we don't require -- or permit -- logins on the gateway
machine.  Incoming users must log in as ``guard'', which goes
through a challenge/response protocol with a hand-held authenticator
the user must have.  There are too many password collectors on the
Internet....


        --Steve Bellovin

------8<------8<------8<------8<------8<------8<------8<------8<------8<------

Date: Fri, 26 Apr 91 00:42:15 +0200
From: [e-mail] (Geert Jan de Groot)
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: need firewall
Sender: [e-mail]

[I can't remember wether or not it is allowed to have discussions on sun-nets;
if not, I apologise for the protocol error..]

It has been said that:
>Only allow connections with port numbers > 1000, and a machine is safe.

Unfortunately, it isn't that easy.
First, one has to switch off UDP completely, I'm afraid. Usually, on UDP
port 2049, one finds the NFS server. It takes a lot of effort to get data
this way, but it is possible. There might be other services on high UDP
numbers too.

Second, usually there are TCP services on ports > 1000. If I look at
the machine I'm typing now, I see that ypbind is reachable on port
1027. I think (but haven't tried) that it is possible to obtain a NIS
copy from /etc/passwd that way.

'netstat -a', and 'rpcinfo -p' shows most of the evil.

Does anybody have s solution for these problems? I can think of disabling
all RPC functions, NIS, NFS, and some 'classic' WKS services, but that
cripples the machine making it useless for almost anything else.
There must be a better way. Am I wrong here?

Geert Jan


--8<--nip-nip---------------------------------------------------------------
"We trained hard - but it seemed that every time we were beginning to form up
into teams, we would be reorganized. It was to learn later in life that we tend
to meet any new situation by reorganizing, and a wonderful method it can be
for creating the illusion of progress while producing confusion, inefficiency,
and demoralisation." - Petronius, 100 BC

Geert Jan de Groot, Philips ICA, Weisshausstrasse 1, 5100 Aachen, Germany
Email: [e-mail] or ..!hp4nl!philica!geertj
Phone: [phone]  FAX: [phone]

------8<------8<------8<------8<------8<------8<------8<------8<------8<------

Message-Id: <[e-mail]>
To: [e-mail] (Geert Jan de Groot)
Cc: [e-mail], [e-mail]
Subject: Re: need firewall
In-Reply-To: Your message of "Fri, 26 Apr 91 00:42:15 +0200."
                <[e-mail]>
Date: Thu, 25 Apr 91 22:19:24 -0400
From: [e-mail]
Sender: [e-mail]

Yes, there are a few ports up there you might want to protect,
but they are relatively easy to find, and are probably isolated
to just a few machines (YP servers, etc), so this is still a
very reasonable approach.  In particulary, it doesn't wreck
the notion of "your workstation IS on the the network" like
the simple-minded one-trusted-host gateway approach.

But it is VERY important to use something like a Cisco which
was DESIGNED for this kind of task....

    Cheers,
    -Mike

------8<------8<------8<------8<------8<------8<------8<------8<------8<------

Message-Id: <[e-mail]>
To: [e-mail]
Cc: [e-mail], [e-mail],
        Keith McNeill <[e-mail]>, [e-mail],
        [e-mail]
Subject: Re: Need firewall telnet/ftp gateway
In-Reply-To: Your message of "Thu, 25 Apr 91 16:58:22 PDT."
                <[e-mail]>
Date: Thu, 25 Apr 91 22:22:21 -0400
From: [e-mail]
Sender: [e-mail]


You don't actually have to axe EVERYTHING.  Again, you can selective
axe things on a host-by-host basis, and you can leave some services
even in the "well known port" area if you trust the implementation
on the selected machines.  Yes, you can knee-jerk, or you can do
a little more work and preserve more.

    -Mike

------8<------8<------8<------8<------8<------8<------8<------8<------8<------

Subject: Re: Need firewall telnet/ftp gateway
In-Reply-To: Your message of Thu, 25 Apr 91 14:49:51 EDT
Reply-To: [e-mail]
Date: Thu, 25 Apr 91 16:58:22 -0700
From: Brent Chapman <[e-mail]>
Sender: [e-mail]

#     I had set up a similar configuration for a (nominally) "secure"
# system here at Rutgers.    On the cisco router closest to the machine,
# I only allowed connections with port numbers > 1000 (where the
# machine started allocating ports for outgoing connections).  Since
# the remote hosts must contact a WKS, and the WKSs are below 1000,
# they would fail.   Outbound connections behave properly, though.

Not all well known services are below 1024.  The _published_ ones are,
but there's one particularly troublesome one that isn't, and that's
the X window system.  X listens at port 6000.  I don't know enough
about X to know whether or not somebody can read what's displayed on
my screen when I'm running X, but I assume that they can.  If you
don't want "outsiders" to be able to do this, you need to block port
6000 as well as ports below 1024.

Further, you probably want to block all UDP packets, regardless of
port.  About the only service that this cuts off that you might really
care about is Domain Name Service (port 53).  The reason for cutting
off UDP packets is that RPC-based services (such as NFS) show up at
more-or-less random UDP port number (assigned by the 'portmap'
process) in the <1023 range.  I say "more or less" random, because
they're probably too random to allow you to effectively block _just_
the ports that NFS is going to use, but not random enough to keep an
outsider from being able to find them (after all, he only has 1024
different possibilities to check).


-Brent
--
Brent Chapman                                   Telebit Corporation
Sun Network Specialist                1315 Chesapeake Terrace
[e-mail]                Sunnyvale, CA  94089
                                                Phone:  [phone]

------8<------8<------8<------8<------8<------8<------8<------8<------8<------

Date: Fri, 26 Apr 91 15:42:45 EDT
From: [e-mail] (Brad L. Knowles)
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: Need a Firewall system...
Sender: [e-mail]

Folks,

Keith McNeill (<[e-mail]>), says
(in <[e-mail]>):

KM> We are setting up an internet gateway at work.  Currently, we're going
KM> to set it up as a firewall system.

And later asks for help setting up a proxy-ftp and proxy-telnet system.

    My first question is: Why a firewall system?  Is it because David
Curry in "Improving the Security of Your Unix System" recommends it?

    Mitch Wright, System Administrator for a large network of machines
owned by 7th Communications Group of the United States Air Force (here in
the Pentagon), administrator for the Sun-386i mailing list, and in
general, a knowledgeable kind of guy about Unix says that a firewall
system is not necessary if you set up the security on all of your systems
to be as good as that of your proposed firewall system.  Additionally,
Mitch says that if you are dependant upon your firewall system to protect
you from system crackers, and they crack into your firewall system (based
upon the presumption that no useful system is 100% cracker-proof), then
you are left wide open to any attacks they may make.  In fact, you may be
even more vulnerable because the security on your other system might be
even more lax than it would be otherwise, because you were lulled into a
false sense of security because of your firewall system.  It was Mitch's
arguments that convinced me that David Curry was wrong, perhaps even
dangerously so.

    The short of it is, with good security practices on all of your
machines, nothing like what happened to Clifford Stoll (written about in
"The Cuckoo's Egg") is likely to happen to you.  No matter what machine
they crack into, it is just as tough for them to crack into any of your
other machines as it was for them to crack into the first.  Yes, it does
require additional work on your part, but with good perl and rdist
scripts, combined with cron jobs, you should be able to reduce this
workload significantly.  Additionally, you really do get a lot more
security, not just the illusion of more security.

    If you want to talk to Mitch directly on this subject, so that he can
get into a more detailed discussion of the subject, his e-mail address is
"[e-mail]".

My second question is: Do you really know what you would be letting
yourself into by trying to set up a proxy-ftp and proxy-telnet system?

Two vendors that I am aware of have done this in the past (although they
may or may not currently have this kind of set up), Sun Microsystems and
Digital Equipment Corporation.  Both had to write their own custom
proxy-ftp and proxy-telnet software, which they appear to have kept
proprietary.  I understand that there is some work going on in an IETF
about standardizing on this kind of thing, but I don't know how far along
they are.  Jon Postel might be able to update you, but I would guess that
he has so many RFC's that he is editing that he doesn't really have the
time to stay up-to-date on this stuff.

Mike ([e-mail]), later says (in
<[e-mail]>):

MO> Another alternative is to install (for example) a Cisco gateway that
MO> allows incoming packets for telnet, ftp, etc to go to ONLY the gateway
MO> machine, but allows outgoing packets to the same ports from any machine
MO> to proceed unimpeded.

Wow!  I didn't know that gateways like the cisco were capable of this kind
of thing.  Could you elaborate a little more as to how you set up your
gateway to do this?

Please respond via e-mail.  I will summarize and re-post, if appropriate.
 ________________________________________________________________________
| Brad Knowles                 | Internet: [e-mail]  |
| System Administrator         |       or: [e-mail]      |
| DCA/JDSSC/JNSL               | Ph: [phone]  Fax: [phone] |
| The Pentagon, Room BE685     |_________________________________________|
| Washington, D.C.  20301-7010 | my opinions != DCA's opinions or policy |
|______________________________|_________________________________________|

------8<------8<------8<------8<------8<------8<------8<------8<------8<------

From: Aydin Edguer <[e-mail]>
Message-Id: <[e-mail]>
Subject: Re: Need a Firewall system...
To: [e-mail]
Date: Fri, 26 Apr 91 23:00:51 EDT
In-Reply-To: <[e-mail]>; from "Brad L. Knowles" at Apr 26, 91 3:42 pm
X-Mailer: ELM [version 2.3 PL6]
Sender: [e-mail]

>     The short of it is, with good security practices on all of your
> machines, nothing like what happened to Clifford Stoll (written about in
> "The Cuckoo's Egg") is likely to happen to you.  No matter what machine
> they crack into, it is just as tough for them to crack into any of your
> other machines as it was for them to crack into the first.  Yes, it does
> require additional work on your part, but with good perl and rdist
> scripts, combined with cron jobs, you should be able to reduce this
> workload significantly.  Additionally, you really do get a lot more
> security, not just the illusion of more security.

Whoa!!!  There is a major flaw in this logic.  The use of rdist or perl
scripts assumes a trusted host.  As soon as this trusted host is cracked
then it is trivial to crack the other hosts that rely on the trusted host.
This is actually worse than having a gateway machine or router protecting
your hosts.  The gateway idea does not depend on trust, it just adds an
extra layer of insulation.  This is good.

Aydin Edguer
Facilities Manager
Computer Engineering & Science
Case Western Reserve University

------8<------8<------8<------8<------8<------8<------8<------8<------8<------

Message-Id: <[e-mail]>
To: [e-mail]
Date: Sun, 28 Apr 91 18:00:25 MST
From: [e-mail] (Dave Wade)
Subject: Re: Need a Firewall system...
Sender: [e-mail]


 >
 >      Whoa!!!  There is a major flaw in this logic.  The use of rdist or perl
 >      scripts assumes a trusted host.
 >
 >      Aydin Edguer

But the trusted host can be behind the gateway...  The gateway can be set to
be updatable from said host, and not vice-versa.

------8<------8<------8<------8<------8<------8<------8<------8<------8<------

Message-Id: <[e-mail]>
From: [e-mail] (Steven M. Bellovin)
To: [e-mail] (Brad L. Knowles),
        [e-mail]
Cc: [e-mail]
Subject: Re: Need a Firewall system...
Date: Mon, 29 Apr 91 13:17:35 EDT
Sender: [e-mail]

Brad Knowles cites some arguments by Mitch Wright about why firewall
gateways aren't needed.  With all due respect, I beg to differ.

The first claim made is that if all systems were at the proper security
level, a gateway wouldn't buy you anything.  That just isn't so.  You
can't keep all machines that secure.  Remember that you're not talking
about one organization, you're talking about dozens or hundreds, each
with its own roster of equipment, and its own system administrators.
The operating systems are of varying levels of quality, the bugs will
likely be different, and no one person is likely to know them all.
Furthermore, the administrators are of varying levels of quality, too
-- we've all seen folks who couldn't keep a bank vault secure.

Note, btw, that these assumptions mean that rdist and the like don't
help you much.  Let me put it this way:  if you are responsible for a
group of machines -- and I'm mean *responsible*, i.e., you're on the
carpet if something goes wrong -- are you going to cede administrative
control to some central group?  I wouldn't.

Even if you could do all this, you'd still lose out.  Application-level
gateways can do logging and analysis; packet filters cannot.  Would you
know if someone tried a Morris-style attack on your smtp daemon?  On
any of your machines?  If you've developed logging for that sort of
attack, do you have that code ported to all of your platforms?  Do all
of your administrators look at the logs?  Do they care?  A decent
gateway can take care of this.  (Btw, don't dismiss this case.
According to the media, the Dutch hackers have exploited this very
hole.  I certainly believe that there are still systems with this hole
exposed.  A recent internal security sweep here turned it up.)

A gateway machine can also be stripped down, in a fashion unacceptable
for ordinary machines.  Programs that aren't needed to relay circuits
or mail messages can simply be deleted.  Thus, if you're suspicious of
the line printer daemon, because it runs setuid to root -- nuke it.
Worried about bugs in rcp?  Delete it.  Don't trust NFS?  Build a
kernel without it.  We run our gateway under the principle ``guilty
until proven innocent''.  If a daemon isn't demonstrably necessary,
it's disabled.  (See Cheswick's paper for a list of the security
measures taken to protect our gateway.  Can you -- do you? -- really
take all those measures on every one of your machines?)

Another point Cheswick makes, incidentally, is that we need an
application-level gateway machine in any event.  It's used as an
authentication server -- we do *not* want people to type internal
passwords on insecure machines and networks.  (For what it's worth, I'm
not as worried about packet-sniffing as I am about horsed telnet and
rlogin commands.  But both are threats.)  Instead, we rely on hand-held
authenticators and random challenges.  As a fringe benefit, our gateway
machine doesn't have passwords for most people, because most people
don't have logins on it.

Before you say it -- yes, an existing telnet connection can be
subverted.  Technically speaking, that's a lot harder to do than
ordinary password-stealing.  Our users are cautioned about the
insecurity of the resulting connection.  And of course, the existence
of the telnet gateway means that we know exactly who the users are;
warnings can be targeted.

As for Cisco's packet filters -- yes, they're useful, though I have my
quibbles about a few details.  But I'm not convinced I can write down
an adequately-secure policy.  The things that scare me most are
RPC-based services (because they don't live on fixed port numbers, and
hence can't be filtered), and X11 applications.  The latter are
problematic both because of the complexity of the protocol, and because
the standard ``legal'' activity -- dialing out -- involves a call to a
well-known port number on the inside.  But that same call can be an
attack.  I know how to implement an X11 gateway at the circuit level; I
don't know how to do it at the packet level.

All that said, I agree completely with one point:  no level of security
on an Internet gateway is an excuse for lax internal security.  We do
have our own internal security processes.  These help to protect us
against penetrations by other avenues, or against abuse of facilities
by rogue insiders.

Gateway daemons aren't hard to write.  Ftp is a bit tricky, because
the application has to know about IP addresses and port numbers,
to implement the PORT and PASV commands.  But it's quite doable.

Let me conclude by freely admitting that we've sacrificed something.
We don't have quite as good connectivity; if I need to do certain
sorts of testing, I'm forced to use the gateway machine, a privilege
that most folks here don't have.  (Traceroute is one example.)
But for protecting the resources of the company -- and remember
that I'm not in a university environment -- I think that we've
adopted the best solution.

        --Steve Bellovin

------8<------8<------8<------8<------8<------8<------8<------8<------8<------

Message-Id: <[e-mail]>
To: [e-mail] (Steven M. Bellovin)
Cc: [e-mail] (Brad L. Knowles),
        [e-mail], [e-mail]
Subject: Re: The Bell Labs firewall system
In-Reply-To: Your message of "Mon, 29 Apr 91 13:17:35 EDT."
                <[e-mail]>
Date: Tue, 30 Apr 91 11:54:22 -0400
From: [e-mail]
Sender: [e-mail]

Cheswick's system is certainly interesting and instructive, and the
system I use is also augmented with a hardware authenticator to defeat
password replay threats.  However, I personally feel quite strongly
that in  Cheswick's system has given up more than what others find
acceptable.  This is, however, only MY opinion - one clearly not
universally held! The issue is that the notion of "right solution" is
complex - it is a function of many things, not the least of which is
the nature of the environment you wish to have, and how much people
will tolerate various inconveniences.  Each site must carefullly
evaluate these things themselves.

As a technical aside, Steve should mention that at least some part of
Cheswick's system relys on the characteristics of Datakit for part of
its security.  (According to a possibly dated talk given by Ches.)
Some sites do similar things by creating internal network regions
which are (much) less trusing than other network regions, even if they
are all behind the same firewall.

Anyway, the point is not to try and sell one particular approach, but
rather, to make it clear that there are alternatives.  Using personal
authenticators of some kind appear to be the only real way to stop
password replay attacks, so any scheme will probably adopt those at
some point.  A gateway machine in and of itself doesn't help without
this.

Packet filtering, hardware authenticators, gateway machines and good
overall security practices are certainly all components which can be
used to achieve a locally-acceptable balance between the pain of the
disease and the pain of the cure.  As in most complex areas,
pat answers to hard questions are suspect just on general principles.

    Cheers!
    -Mike

Bellcore??? Bellcore doesn't have opinions, so these MUST be mine!

------8<------8<------8<------8<------8<------8<------8<------8<------8<------

Date: Tue, 30 Apr 91 12:33:13 EDT
From: [e-mail] (Timothy G. Smith - Technical Consultant Sun Baltimore)
Message-Id: <[e-mail]>
To: [e-mail] (Steven M. Bellovin)
Cc: [e-mail] (Brad L. Knowles), [e-mail],
        [e-mail]
Subject:  Re: Need a Firewall system...
Sender: [e-mail]

I meant to send something out about Brad Knowles (and Mitch Wright)
the other day but didn't get to it.  I am glad I didn't.  Steve has
done a much better job than I would.

Whether you go with an application level or network level firewall
depends on a lot of factors.  Two factors way up at the top of my list
are how important the stuff behind the firewall is and what resources
you have available to protect them.

AT&T has a lot to lose if their network is penetrated and has thus
committed some very bright people to solving the problem of protecting
AT&T's internal networks.  These people had the ability and resources
to set up a policy and implement it.  They have built a very impressive
firewall.  Their firewall implementation includes hardware and
software components neither of which were inexpensive to implement.
Someone in their management structure decided that security was
important so the resources were allocated and committed.

I don't know how many other companies are able to go to the lengths
that AT&T has.  A few immediately come to mind (Cray, DEC, IBM, Sun)
but they are all large companies who would have risks and resources
comparable to AT&T's.

I doubt that a "regular" company would have the same resources to
commit although they very well may have the same risk level.

So how does J. Random Company solve the problem?  Good question.

I have an idea or two but they involve, you guessed it, an application
level firewall (although network level firewalls are probably involved
too).

I guess I need to go pull my copy of the USENIX paper to check some
details...

------8<------8<------8<------8<------8<------8<------8<------8<------8<------

Date: Tue, 30 Apr 91 14:23:11 EDT
From: Mitch Wright <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail] (Sun Nets)
In-Reply-To: <[e-mail]>
Subject: Re: Firewall [CORRECTION]
Sender: [e-mail]


/*
 * Steve Bellovin <[e-mail]> writes:
 *
 * Brad Knowles cites some arguments by Mitch Wright about why firewall
 * gateways aren't needed.  With all due respect, I beg to differ.
 *
 */

I'm glad to see my name isn't being used with four letter words, but I see
I still need to clarify a few things...

My discussions with Brad Knowles regarding firewalls was not supposed to
be a solution for everyone.  I was specifically addressing several of our
LANs on this site and highly recommend that other sites draw their own
conclusions based on their respective configurations.  I do, however,
question the use of a firewall as a solution to internal weaknesses.

As for me recommending rdist, nope -- didn't say it.  I do advocate using
perl, but that's another story and clearly unrelated to the topic at hand.

Sorry to waste the bandwidth, but I just wanted to stop all of the snickering
in the office, hall, supermarket...  :-)

    ~mitch

------8<------8<------8<------8<------8<------8<------8<------8<------8<------

Date: Tue, 30 Apr 91 16:31:23 EDT
From: [e-mail] (Timothy G. Smith - Technical Consultant Sun Baltimore)
Message-Id: <[e-mail]>
To: Mitch Wright <[e-mail]>
Cc: [e-mail] (Sun Nets)
Subject:  Re: Firewall [CORRECTION]
Sender: [e-mail]

< I do, however, question the use of a firewall as a solution to
< internal weaknesses.

Many times the firewall is not being used as "a solution to internal
weaknesses".  Rather it is being used as a valve between an
environment that is hostile (the Internet at large) and an environment
that is non-hostile (a private network where security is not quite
such a big deal).  The idea is to keep the bogons out without getting
in the way of the good guys.

In some of the places I work the rule is tighten everything down as
far as it will go.  In other places the rule is to provide just enough
security to prevent accidental or casual snooping.  Even within a
single site there are widely varying security requirements; Personell
and Finance have their security motto ("Don't let anyone see anything
without explicit authorization!") while Engineering has its own vastly
different ("Let all of *us* see everything but keep *them* from seeing
anything.").

< I was specifically addressing several of our LANs on this site and
< highly recommend that other sites draw their own conclusions based on
< their respective configurations.

I think everyone will have to agree.  What it all seems to boild down
to is:  "How important is security to you (or your company) and what
are you willing to do about it?"

------8<------8<------8<------8<------8<------8<------8<------8<------8<------

Message-Id: <[e-mail]>
To: [e-mail]
Cc: [e-mail], [e-mail],
        [e-mail] (Brad L. Knowles), [e-mail],
        [e-mail]
Subject: Re: What Steve and I disagree on...
In-Reply-To: Your message of "Tue, 30 Apr 91 15:04:37 EDT."
                <[e-mail]>
Date: Tue, 30 Apr 91 15:37:15 -0400
From: [e-mail]
Sender: [e-mail]

Yes, Steve, you and I certainly agree much, much more than we
disagree, and your summary of the difference is exactly on target.

Next contestant!

    -Mike

------8<------8<------8<------8<------8<------8<------8<------8<------8<------

Message-Id: <[e-mail]>
From: [e-mail]
Date: Tue, 30 Apr 91 13:56:15 EDT
To: [e-mail]
Sender: [e-mail]

[e-mail]  smb [e-mail] [e-mail]

 >Their firewall implementation includes hardware and
>software components neither of which were inexpensive to implement.

Actually, the hardware is pretty cheap these days: 2 computers back-to-back.
The outgoing proxy took probably a man-month, which is admittedly more time
than most would want to spend.  I'd like to release it, though I am not sure
it will get through the software release process.

>Someone in their management structure decided that security was
>important so the resources were allocated and committed.

Dave Presotto and I put the first gateway in place unilaterally.  The Corporation
bought into the idea for the real gateway.  I've found that management is generally
wholeheartedly interested in the security.  The users' enthusiasm varies greatly.

There are certainly large companys who use gateways: Apple, DEC, and (I think)
Mitre come to mind.  There are other companies I may not name that have resisted
any connection to the Internet for fear of losing their secrets.

ches

------8<------8<------8<------8<------8<------8<------8<------8<------8<------

Message-Id: <[e-mail]>
From: [e-mail]
To: [e-mail], [e-mail]
Cc: [e-mail] (Brad L. Knowles), [e-mail]
Subject: Re: The Bell Labs firewall system
Date: Tue, 30 Apr 91 15:04:37 EDT
Sender: [e-mail]

     As a technical aside, Steve should mention that at least some part of
     Cheswick's system relys on the characteristics of Datakit for part of
     its security.

Yes and no.  More or less the same system could be deployed using a pair
of packet filters.  You're best off if you have a second, helper
machine on the inside of the firewall, to avoid problems with routing
tables and the like.  Let me draw a picture.

            |
    (inside)----|
            |
            |               |     |
            |               |     |
    Helper------|               |--AppGw--|
            |               |     |
            |--Router/FilterA--|     |--Router/FilterB----Internet
            |               |     |
            |               |     |
            |               |     |
            |               |     |
            |

Router/FilterB is configured so that only AppGw is a legal packet
destination.  Source routing through it should be disabled.
Router/FilterA protects your inside machines against subversion of
AppGw.  It should have a list of machines that AppGw may talk to,
and the legal port numbers, probably just 25 for SMTP.  The
helper machine will, in general, serve as the recipient for most
or all mail leaving AppGw.  This avoids the necessity of AppGw
needing to know routes to all internal networks, or needing to
access an internal DNS.  (Yes, we run one.)  There are other reasons
as well -- the machines AppGw talks to on the inside should be
secure as well, in case AppGw is subverted.  This is exactly what
Cheswick does, except that Router/FilterA is a Datakit switch,
rather than an IP router.  No matter -- the configuration constraints
are the same.  Using the second technology does help your security
a bit, since it reduces the likelihood of common-mode failures
jeopardizing both AppGw and Helper.  And I'm a bit nervous
about someone squirting ICMP Redirect packets at AppGw, to mess
with its routing tables.  If I had kernel source, I think I'd
disable them.

For the pure IP case, you can simplify things a bit by having
Router/FilterA, AppGW, and Router/FilterB all living on a single
LAN.  I think that that can be made secure, though more care is
needed -- Router/FilterA no longer has any assurance that packets
arriving at it really originated at AppGw, and the two routers
have to be careful not to exchange routing data.

For those who quail at the thought of two machines and two routers,
I submit that you really need the two extra machines in any event,
at least for a large installation.  AppGw is probably needed as a
mail and news gateway.  There are many operational advantages
to having mail carry a common return address, and having it queued at
a single point.  There are many such machines around that have
no major security motivation, including ulysses, the uucp `research'
machine, ucbvax, and allegra.  (To be sure, the instigators of
these machines were not unaware of the security benefits.)  The
second machine is necessary if you're using hand-held authenticators;
today's technology means that someone needs to store their keys
in plaintext, and that's a very dangerous thing to put on a general-
purpose machine.  Additionally, users are (in effect) going to rlogin
from the gateway machine to their own hosts; thus, that machine has
to be very trustworthy, because your whole internal network is
trusting it.  If you're worried (paranoid?) about security, you
*don't* want that sort of machine on the outside.

     Packet filtering, hardware authenticators, gateway machines and good
     overall security practices are certainly all components which can be
     used to achieve a locally-acceptable balance between the pain of the
     disease and the pain of the cure.  As in most complex areas,
     pat answers to hard questions are suspect just on general principles.

Absolutely.  On this we agree completely.  (In fact, I doubt we
disagree on much, except for the level of the threat compared with the
level of defenses affordable.)  The scheme I describe above is for the
truly-paranoid; there are many simplifications possible in appropriate
environments.  I'll leave those as an exercise for the reader.  Point
two in my standard security lecture is that security is always a
tradeoff with convenience -- you have to pick the right measures for
each situation, depending on what you're protecting, and against whom.
I doubt I'd adopt a scheme like this for a university's academic
computing center.


        --Steve Bellovin

------8<------8<------8<------8<------8<------8<------8<------8<------8<------

Date: Tue, 7 May 91 16:26:09 EDT
From: [e-mail] (Brad L. Knowles)
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Apologies, corrections and explanations...
Sender: [e-mail]

Folks,

    First, let me publicly apologize to Mitch for using his name as a
reference for ideas that he did not generate.

    Second, the bad idea of using perl, rdist and cron was mine -- I know
Mitch isn't that ignorant, although I clearly was.

    Third, as I'm sure has been said here before, how much security a
particular installation needs is very situationally dependant.  The same
installation may even need differing levels of security, depending upon
their situation at any particular time.  Some installations need to be on
the Internet, and *must* still have very high levels of security.  In that
case, I am still convinced that they must have maximum levels of security
possible on *all* machines connected to the Internet, directly or
otherwise.  Whether they have a firewall or not is not relevant -- a
firewall would help, but if they have poor security behind the firewall,
then they might as well not even have the firewall -- some cracker is
guaranteed to crack into the firewall sooner or later, so maximal security
behind the firewall is still needed.

In this case, "maximal security" may even be defined differently for
different folks or different situations -- my definition may be Orange
Book B1, while yours may be "Good enough to keep the causual
Freshman-level cracker out" (or vice-versa, obviously).

To put it bluntly, a firewall is not enough (IMO) -- you must have decent
security behind the firewall, otherwise you are just setting yourself up
for a fall that will *really* hurt!

    I apologize for not replying sooner, but I just got *really* busy, so
I haven't read the last 300 messages that I have sitting in my mailbox
(not just sun-nets, but sun-managers, sun-spots, and a whole long list of
others).

        -Brad
        Tue May  7 16:25:04 EDT 1991

------8<------8<------8<------8<------8<------8<------8<------8<------8<------

Message-Id: <[e-mail]>
To: "Brad L. Knowles" <[e-mail]>
Cc: [e-mail]
Subject: Re: To firewall or not (was: Apologies, corrections and explanations...)
In-Reply-To: Your message of Tue, 07 May 91 16:26:09 -0400.
                <[e-mail]>
Date: Tue, 07 May 91 18:03:40 -0400
From: [e-mail]
Sender: [e-mail]

> ... some cracker is guaranteed to crack into the firewall sooner or later,
> so maximal security behind the firewall is still needed.

I'm puzzled by this line of argument.  The firewall system will
presumably have the best security that the organization is capable of
devising--the equal or better of the security on any system behind it.
So once someone does succeed in cracking through the firewall, that
same cracker is not going to find it very hard to get through any
other system behind it, even if they are "maximally" secure.  At best,
making them "maximally" secure--as secure as the firewall--will slow
the cracker down a bit.  So why is maximal security behind the
firewall desirable?

    Dan Franklin

------8<------8<------8<------8<------8<------8<------8<------8<------8<------

To: [e-mail]
Cc: "Brad L. Knowles" <[e-mail]>,
        [e-mail]
Subject: Re: To firewall or not (was: Apologies, corrections and explanations...)
In-Reply-To: Your message of Tue, 07 May 91 18:03:40 -0400.
                <[e-mail]>
Date: Wed, 08 May 91 18:10:51 +0000
Message-Id: <8989.673690251@munnari>
From: Robert Elz <[e-mail]>
Sender: [e-mail]

    Date:        Tue, 07 May 91 18:03:40 -0400
    From:        [e-mail]
    Message-ID:  <[e-mail]>

    > ... some cracker is guaranteed to crack into the firewall sooner or later,
    > so maximal security behind the firewall is still needed.

    I'm puzzled by this line of argument.

I suspect that the idea is that to "crack" the firewall, you
don't actually need to get very far into it, just some way
to get packets through it, or the ability to log in as any
user at all, etc.

But if you're depending on that for most of your security,
and your internal security were more lax, then someone who
manages to get just a toehold into the firewall will possibly
be able to get much further than that on your internal systems.

On the other hand, if your internal security is as good as
security on your firewall, then someone who manages only a
minor break into that probably won't be able to do more than
make a minor break into the internal nodes either.

kre

------8<------8<------8<------8<------8<------8<------8<------8<------8<------

Date: Wed, 8 May 91 09:33:39 EDT
From: [e-mail] (Don Wells)
Message-Id: <[e-mail]>
To: [e-mail]
In-Reply-To: <8989.673690251@munnari>
Subject: Re: To firewall or not (was: Apologies, corrections and explanations...)
Sender: [e-mail]

Robert Elz writes:
 >     Date:        Tue, 07 May 91 18:03:40 -0400
 >     From:        [e-mail]
 >     Message-ID:  <[e-mail]>
 >
 >     > ... some cracker is guaranteed to crack into the firewall sooner or later,
 >     > so maximal security behind the firewall is still needed.
 >
 >     I'm puzzled by this line of argument.
...
 > ...if your internal security is as good as
 > security on your firewall, then someone who manages only a
 > minor break into that probably won't be able to do more than
 > make a minor break into the internal nodes either.

As with security in non-computer situations, the *real* threat is
always insider jobs, usually unhappy former employees. Such a person
has a special advantage in attempting to crack through the firewall,
and also is likely to have special knowledge and special incentive to
do damage to any insecure systems behind the wall. It is simply not
prudent to trust the firewall as the only line of defense.

For building security we do not consider the external locks and guard
service to be sufficient; internal high-value labs and internal
offices containing sensitive information have independent locks, and
even have locked cables attached to computers and locked cabinets
inside locked rooms (3-layer security). This is considered to be
prudent practice in non-computer contexts, and it suggests some
reasonable precautions for computer security. We have no illusions
that the building locks will keep a *really* determined person out of
our buildings and offices and labs, of course, and likewise we should
not have any illusions about the ultimate effectiveness of computer
security efforts.

In my opinion, "firewalls" are a bad idea for computer security,
because they tend to lead to bad practices in internal security due to
improper attitudes. The non-computer analogy which I recommend is an
industrial park, or industrial campus, in which multiple buildings are
exposed to breakins separately. The management will want to install a
fence around the whole park, of course (the "firewall"), but it will
be imprudent for them to then assume that they won't need to lock the
*individual* buildings and lock the internal cabinets containing
personnel records and lock the internal labs containing the industrial
secrets. It will also be imprudent for them to assume that they won't
need a night-time guard force to monitor the whole facility. They
should lock the doors leading to the utility tunnels that connect the
buildings, of course.  The industrial park is like our LANs...

Donald C. Wells             Associate Scientist        [e-mail]
National Radio Astronomy Observatory                   [phone]
Edgemont Road                                     Fax= [phone]
Charlottesville, Virginia 22903-2475 USA            78:31.1W, 38:02.2N

------8<------8<------8<------8<------8<------8<------8<------8<------8<------

Date: Wed, 8 May 91 10:25:01 EDT
X-Mailer: Mail User's Shell (6.5 4/17/89)
From: Keith McNeill <[e-mail]>
To: [e-mail]
Subject: SUMMARY: Need firewall telnet/ftp gateway
Message-Id:  <[e-mail]>
Sender: [e-mail]


Many people asked for a summary on the responses that I got on my proxy
telnet/ftp query.

First my original note:

]
]
]We are setting up an internet gateway at work.  Currently, we're going
]to set it up as a firewall system.  A problem with this setup is that
]anybody in the company who wants to telnet/ftp to the internet has to
]have an account on the firewall system, an administration nightmare.  I've
]heard about some software that you put on the gateway that acts as a
]telnet/ftp intermediary.   The software consists of a modified telnet/ftp
]for inside our network which connects to intermediary software that is put
]on the firewall gateway.  The intermediary software then makes the telnet/ftp
]connections out on the internet.
]

Now the "answer":

If your firewall is a Sun & you have lots of Sun's in your organization then
you are all set.  Sun has a (or is about to release) a Consulting Special
called Itelnet/Iftp which is a proxy telnet/ftp server.  Call your local Sun
office for information on "Consulting Specials".  If you don't have Sun's I
heard from somebody at Sun that the consulting group ***may*** be willing to
port...for a price.

Some people mentioned AT&T's paper on their Internet gateway.  I still haven't
been able to relocate my copy but if memory serves me I think that their
setup is specific to AT&T & their Datakit network.  Please correct me if I
am wrong.

Many, many people mentioned using a router (most people mentioned Cisco) to
do packet filtering.  A couple people had an interesting firewall/router
debate going on for awhile, but I don't think that there is a correct
answer.  As with most computer/network configurations it all depends on the
structure & people of your company/organization as to which is the better
solution.

If you decide to go the router "route" some people suggested that among the
obvious ports to restrict that you restrict UDP packets to block Sun RPC's
(including yellow pages & NFS) and TCP port 6000 to block X11.

There is also some software that enables you to disallow connections from
certain hosts/domains at certain ports.  You can get it via anonymous ftp at
cert.sei.cmu.edu in pub/network_tools.

Many thanks to:

Richard Cower <[e-mail]>
[e-mail]
Bill Lewandowski <[e-mail]>
"Jerry M. Carlin" <[e-mail]>
"Timothy G. Smith" <[e-mail]>
[e-mail]
William Clare Stewart <[e-mail]>
Michael O'Connor <[e-mail]>
"Anthony A. Datri" <[e-mail]>
"Randal L. Schwartz" <[e-mail]>
"Kenneth R. van Wyk" <[e-mail]>
Tp Brisco <[e-mail]>
Brent Chapman <[e-mail]>
[e-mail]
David Pipes x4552 <srg![e-mail]>
David Richardson <[e-mail]>
Sean Kelly <[e-mail]>
"Ted R. Doty" <[e-mail]>
Chris Sherman <[e-mail]>
David Neal <uunet!sun.rice.edu![e-mail]>
[e-mail]
Phil Meyer <[e-mail]>


and all the other people who responded.  I got close to 40 responses within
24 hours!  Once again the Internet proves its worth!!


Keith

    Keith McNeill                 |   1131 North Broom Street
    [e-mail]              |   Wilmington, Delaware, 19806
                                  |   [phone]

------8<------8<------8<------8<------8<------8<------8<------8<------8<------

Message-Id: <[e-mail]>
From: [e-mail]
To: Keith McNeill <[e-mail]>
Cc: [e-mail]
Subject: Re: SUMMARY: Need firewall telnet/ftp gateway
Date: Wed, 08 May 91 12:01:10 EDT
Sender: [e-mail]

     Some people mentioned AT&T's paper on their Internet gateway.
     I still haven't been able to relocate my copy but if memory
     serves me I think that their setup is specific to AT&T & their
     Datakit network.  Please correct me if I am wrong.

OK, consider yourself corrected.  While the current implementation
does use Datakit, there is no conceptual dependence on it.  I could
implement the same thing with, say, a Cisco router.  I sent a long
message to this mailing list explaining exactly how things are
set up, and what the requirements are for the firewall router.

        --Steve Bellovin

------8<------8<------8<------8<------8<------8<------8<------8<------8<------

From: Aydin Edguer <[e-mail]>
Message-Id: <[e-mail]>
Subject: Re: To firewall or not (was: Apologies, corrections and explanations...)
To: [e-mail]
Date: Wed, 8 May 91 11:34:43 EDT
In-Reply-To: <[e-mail]>; from "[e-mail]" at May 7, 91 6:03 pm
X-Mailer: ELM [version 2.3 PL6]
Sender: [e-mail]

> > ... some cracker is guaranteed to crack into the firewall sooner or later,
> > so maximal security behind the firewall is still needed.
>
> I'm puzzled by this line of argument.  The firewall system will
> presumably have the best security that the organization is capable of
> devising--the equal or better of the security on any system behind it.
> So once someone does succeed in cracking through the firewall, that
> same cracker is not going to find it very hard to get through any
> other system behind it, even if they are "maximally" secure.  At best,
> making them "maximally" secure--as secure as the firewall--will slow
> the cracker down a bit.  So why is maximal security behind the
> firewall desirable?

"Security is only as good as the weakest link." - somebody, I am sure.

The first advantage of all firewall systems is that it is much easier to keep
track of and log all usage of the firewall.  This is something that may be
impossible or at least impractical to do with all the systems behind a firewall.
Thus the probability of detection of a break-in is much higher using a
firewall than by allowing all the systems equal access to the outside network.

Thus firewalls are good and an improvement over just maximally securing
all hosts on a network because detection is an important step in protection.
But detection of a break-in, after the fact is of little value.

There are more than one type of firewall system.  There have been a couple
discussed briefly in previous messages.  In general however, they have one
thing is common, they run software/hardware which is different from that
found on the machines behind the firewall system.  Whether this means
a router that has "fascist" filtering or a gateway system running locally
written applications with challenge-response authentication or a pair
of systems connected by a DATAKIT network rather than TCP/IP or a combination
of these and other methods, breaking the firewall does not guarantee breaking
into the systems behind the firewall, if they are maximally secure, unless
given time to develop a new method of break-in.  If the network users are lax
in their measures and fail to protect their machines then the time lag between
detection of the break-in and the shutdown or repair of the firewall is
greater than that needed by the cracker to get into the interior systems.

There are a number of ideas behind firewalls, but being the only line
of defense is usually not one of them.  Just because a method is found to
crack the firewall, there is no reason to give up on the assumption that
the cracker must find or develop the tools to break the other systems.
Maximal security behind the firewall gives an organization more time and
chances to detect a cracker before the cracker can obtain sensitive information
or do damage.

Aydin Edguer

------8<------8<------8<------8<------8<------8<------8<------8<------8<------

Message-Id: <[e-mail]>
To: [e-mail] (Don Wells)
Cc: [e-mail]
Subject: Re: To firewall or not (was: Apologies, corrections and explanations...)
In-Reply-To: Your message of Wed, 08 May 91 09:33:39 -0400.
                <[e-mail]>
Date: Wed, 08 May 91 13:43:21 EDT
From: "Manavendra K. Thakur" <[e-mail]>
Sender: [e-mail]

>>>>> On Wed, 8 May 91 09:33:39 EDT, [e-mail] (Don Wells) said:

> In my opinion, "firewalls" are a bad idea for computer security,
> because they tend to lead to bad practices in internal security due
> to improper attitudes. The non-computer analogy which I recommend is
> an industrial park, or industrial campus, in which multiple
> buildings are exposed to breakins separately. The management will
> want to install a fence around the whole park, of course (the
> "firewall"), but it will be imprudent for them to then assume that
> they won't need to lock the *individual* buildings and lock the
> internal cabinets containing personnel records and lock the internal
> labs containing the industrial secrets. It will also be imprudent
> for them to assume that they won't need a night-time guard force to
> monitor the whole facility. They should lock the doors leading to
> the utility tunnels that connect the buildings, of course.  The
> industrial park is like our LANs...

Don, there's a key phrase missing from the above paragraph.  You say
"The non-computer analogy which I recommend ...."

My question is: recommend to whom?  To anybody interested in "computer
security"?

I hope not!

The last sentence implies that the National Radio Astronomy
Observatory has implemented such severe levels of security, or that
you personally would recommend to the NRAO management that they
implement such levels of security.  Is this true?  The reason I'm
asking is that I'm wondering what security needs (as opposed to
specific implementation goals) led you to make such a recommendation
to the management at NRAO?

Speaking as a computer-literate person at another scientific
astronomical research facility, I think you (or someone at NRAO) may
have miscaculated.  Just what are scientists doing there at NRAO that
could possibly require the severe levels of security you describe in
your analogy?

If the security need at NRAO is to simply ensure that 1) your systems
are functional and available without unnecessary interruptions and 2)
that the sole-access rights of Principal Investigators to their
scientific data is preserved, then are all those levels of security
really needed?  If so, can you explain a bit why?

Aside from all the privacy and ethical issues revolving around
security matters -- particularly in an academic research environment
-- there remains the fundamental practical rule that the cost of the
security should not be greater than the value of whatever it is that
the security is designed to protect.  Very rarely in the academic
research world is security the all-or-nothing game that it appears to
be with some corporations, the military, and some government
organizations.

I know that you know all this, as does just everybody else involved
with this discussion, so I'm baffled as why it sounds as though you're
automatically recommending such high levels of security to anybody
interested in "computer security."

So I hope you have a few moments to elucidate a bit on your comments.

Of course, I apologize in advance if I've misconstrued your comments
or taken them out of context somehow.

Manavendra K. Thakur             Internet: [e-mail]
Systems Programmer, High Energy Division BITNET:   [e-mail]
Harvard-Smithsonian Center for         DECNET:   CFA::thakur
Astrophysics                 UUCP:       ...!uunet!mit-eddie!thakur

------8<------8<------8<------8<------8<------8<------8<------8<------8<------

Date: Wed, 8 May 91 18:38:56 EDT
From: [e-mail] (Don Wells)
Message-Id: <[e-mail]>
To: [e-mail]
In-Reply-To: <[e-mail]>
Subject: Re: To firewall or not (was: Apologies, corrections and explanations...)
Sender: [e-mail]

"Manavendra K. Thakur" writes:
 > I know that you know all this, as does just everybody else involved
 > with this discussion, so I'm baffled as why it sounds as though you're
 > automatically recommending such high levels of security to anybody
 > interested in "computer security."

Construe my words carefully, Manavendra, and make the obvious
inferential extensions of them, and you will see that there is no
inconsistency between your positions and mine.

I do indeed advocate that it is a good thing to use non-computer
security analogies when thinking about computer security policies and
techniques. This approach will tend to avoid panic over-reactions to
the problem, the kind of reactions which lead to terrified systems
managers insisting that they absolutely must ensure that *no* foreign
packets will ever be able to enter and traverse their LANs. The
equivalent levels of physical security of buildings or property would
be ludicrous except in national security contexts (and they are often
ludicrous there too!). In physical security we generally only try to
deter and delay, *not* to absolutely prevent, and reasonable computer
security usually should have only analogous goals. It is in this sense
that attempts to establish *impervious* "firewalls" usually represent
improper thinking.

If you do have something valuable/sensitive to protect, then assure
that each of your machines that need protection get it, individually.
Consider adding a firewall of some sort, but don't use it as an excuse
to avoid the duty to provide prudent protection for the hosts behind
the firewall. It is in this context that I suggested the industrial
park analogy.

If you don't have anything valuable/sensitive to protect, then you
don't need to invest very much in security, as you say. Your
non-profit research lab and mine are in this category. You asked what
I have recommended to NRAO's Computer Division. I have recommended
only the usual prudent practices appropriate for an academic research
environment, nothing that would surprise or dismay you. The quote I
like in this context is: "computer security is to information control
as a chastity belt is to birth control".

A special question arises when real-time systems controlling valuable
equipment are exposed to WANs.  It is not sufficient to simply say:
"You should never do that!" This is the 90's, and distributed RT
control is an operational reality. Firewalls of some sort seem to me
to be appropriate, perhaps merely static routes in gateways. Of course
appropriate authentication must be used with all protocols, especially
the custom protocols used for the remote control.

I apologize for any aspects of my wording which may have misled you
about my attitudes, Manavendra.

Regards,
Don

Donald C. Wells             Associate Scientist        [e-mail]
National Radio Astronomy Observatory                   [phone]
Edgemont Road                                     Fax= [phone]
Charlottesville, Virginia 22903-2475 USA            78:31.1W, 38:02.2N

------8<------8<------8<------8<------8<------8<------8<------8<------8<------

Message-Id: <[e-mail]>
To: [e-mail]
Cc: "Brad L. Knowles" <[e-mail]>,
        [e-mail]
Subject: Re: To firewall or not (was: Apologies, corrections and explanations...)
In-Reply-To: Your message of Tue, 07 May 91 18:03:40 -0400
Reply-To: [e-mail]
Date: Thu, 09 May 91 10:24:34 -0700
From: Brent Chapman <[e-mail]>
Sender: [e-mail]

# > ... some cracker is guaranteed to crack into the firewall sooner or later,
# > so maximal security behind the firewall is still needed.
#
# I'm puzzled by this line of argument.  The firewall system will
# presumably have the best security that the organization is capable of
# devising--the equal or better of the security on any system behind it.
# So once someone does succeed in cracking through the firewall, that
# same cracker is not going to find it very hard to get through any
# other system behind it, even if they are "maximally" secure.  At best,
# making them "maximally" secure--as secure as the firewall--will slow
# the cracker down a bit.  So why is maximal security behind the
# firewall desirable?
#
#     Dan Franklin

I look at it this way: I don't expect the firewall system to stop a
determined attacker.  I expect it to keep out the random riff-raff,
and to slow down a determined attacker enough to give me a fighting
chance to notice them and cut them off.  I don't necessarily look at a
firewall system as a magic barrier to keep insiders in and outsiders
out; I look at it as a gatehouse where I can more carefully examine
who goes in and out, without the distraction of "regular" users and
all their processes.

In my opinion, the best security is layered security, preferably with
some different technology in the different layers.  For instance, at
Telebit, as you go outward to inward through the layers, you have
(among other things; I'm not about to reveal my whole bag of tricks in
public!):

    A NetBlazer router doing packet filtering.
    An "external" subnet that has no traffic on it that isn't inbound
        from or outbound to the outside world (in other words, it has
    no company-internal traffic on it).
    A Sun host that does _nothing_ but gateway functions, and has _no_
        users (which makes it much easier to monitor for "unusual activity").
    More NetBlazer routers between the external subnet and the
        internal networks, doing various types of filtering.
    Workstations with a certain (although less than optimal, from my
        point of view) amount of internal security.
    A few other tricks and traps scattered about.

I don't expect _any_ of these systems, individually or in concert, to
stop a truly determined attacker.  I do expect them to slow him down a
bit, and force him to use channels that I'm intimately familiar with
and can more easily monitor and police.


-Brent
--
Brent Chapman                                   Telebit Corporation
Sun Network Specialist                1315 Chesapeake Terrace
[e-mail]                Sunnyvale, CA  94089
                                                Phone:  [phone]

------8<------8<------8<------8<------8<------8<------8<------8<------8<------

Date: 29 Apr 91 20:55:08 GMT
From: waikato.ac.nz!comp.vuw.ac.nz!cc-server4.massey.ac.nz![e-mail]  (Glen Eustace)
Organization: Massey University, Palmerston North, New Zealand
Subject: Re: Setting up a Firewall system, proxy-ftp and proxy-telnet, ...
Message-Id: <[e-mail]>
References: <[e-mail]>, <[e-mail]>
Sender: [e-mail]
To: [e-mail]

Our solution to the host security situation would involve 2 major
components.  1 Our intended firewall machine, and 2 our Cisco router.
 The Cisco can be setup to only allow certain kinds of IP connections
to and/or from hosts that match specific conditions.

Our intention had been to provide all of our other hosts with a
version of telnet and ftp etc. that connected internally to the
firewall machine and then had it connect to the outside world via the
cisco.  As has already been posted, the problem is the software.  We
need a client front end for the various utilities, telnet, ftp etc.
and a server that could run on the firewall machine.

e.g.

     Client ------------> Firewall Host -------> Cisco -----> Internet

The Cisco would be setup to only allow outgoing telnet and ftp from
the Firewall Host.

--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Glen Eustace, Systems Software Manager | EMail: [e-mail]
 Computer Centre,  Massey University,  Palmerston North,  New Zealand
Phone: [phone] x7440, Fax: [phone],       Timezone: GMT-12